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(57) Abstract: The invention concerns a 
method for storing information objects or 
objects (5) in a relational database (2) stored 
in a server computer (1), the relational database 
(2) consisting of tables, each formed by a 
table of single data sets having the same data 
structure in a common table, each single data 
being designated by a single identifier in said 
table, an object (6) consisting of one or several 
single data capable of being stored in a table of 
the database (2), and/or one or several objects 
nested in said object. The nesting can be 
produced on any number of levels to produce 
an object (6), a nested object or a single 
data said to be locally in fixed number if it 
appeals exactly once in the object immediately 
containing it and said to be locally in variable 
number otherwise. A single data occurring at 
a particular level of said object (6) is said to be 
globally in fixed number if it is locally fixed 
and all the objects containing it are in fixed 
number, a single data occurring at a particular 
level of said object is said to be invariable 
number if it is locally in variable number or if 
any one of the objects containing it is locally in variable number. The data globally in Fixed number of an object to be stored (6) 
are stored in a main data set (31) stored in a main table (3) of the database (2). The single data globally in variable number of said 
object to be stored (6) are stored in one or several auxiliary tables (4, 5, 7) of the database (2). When they exist, the single data 
globally in variable number of said objects (6) ate stoned in a single auxiliary table (7) of the database. The method create one or 
several sets of auxiliary data sets (71) to store single data globally in variable number in the single auxiliary table (7). 

(57) AbvOge : Precede de stockagc d'objets informationncls ou objets (6), dans une base de donnccs relationnelle (2) s!ock6e dans 
un ordinateur serveur (1 ), la base de donnfies relationnelle (2) dtant constituee do tables, chacune constitute d 'un tableau d 'ensembles 
de donnees simples qui ont 
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la meme structure de donnees dans une meme table, chaque donnee simple d'unc table est designee par un identifiant unique dans 
ladile [able, un objet (6) dtanl constitue d' une ou plusieurs donnees simples pnuvant Sire stockees dans une table de la base de donnees 
(2), et/ou d'un ou plusieurs objets embolus dans ledit objet. L'emboitement pent @tre realist sur un nombre quelconque de niveaux 
pourrealiser un objet (6), un objet cmboire ou une donnee simple 4tant dit localement en nombre fixe s'ii ou elle apparart exactement 
une fois dans 1'objet le ou la contenant immediatement et etant dit localement en nombre variable dans le cas contraire. Une donnee 
simple apparaissant a un niveau quelconque dudit objet (6) est dite globalement en nombre fixe si elle est localement en nombre fixe 
et si tous les objets la contenant sont localement en nombre fixe, une donnee simple apparaissant a un niveau quelconque dudit objet 
(6) est dite globalement en nombre variable si elle est localement en nombre variable ou si 1' un quelconque des objets la contenant est 
localement en nombre variable. Les donnees globalement en nombre fixe d'un objet a stockcr (6) sont stockees dans un ensemble de 
donnees principal (31) stocke dans une table principale (3) de la base de donnees (2). Les donnees simples globalement en nombre 
variable dudit objet a stacker (6) sont stockees dans une ou plusieurs tables annexes (4, 5, 7) de la base de donnees (2). Lorsqu'elles 
existent, les donnees simples globalement en nombre variable desdits objets (6) sont stockees dans une unique fable annexe (7) dela 
base de donnees, le precede cree un ou plusieurs ensembles de donnees annexes (71) pour stocker les donnees simples globalement 
en nnmbre variable dans I 'unique table annexe (7). 
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PROCEDE DE STOCKAGE D'OBJETS INFORMATIONNELS AU FORMAT 
XML DANS UNE BASE DE DONNEES RELATIONNELLE 

La presente invention a pour objet les proceeds de stockage d'objets 
informationnels, ou objets, dans un systeme informatique, et plus particulierement, 
5 un procede" de stockage, dans une base de donnees relationnelle traditiormelle, 
d'objets au format extended Markup Language, ou XML, du consortium Internet 
World Wide Web, ou W3C. 

Les systemes de stockage de donnees sont bien connus dans les techniques 
de traitement de rinforraation, et de plus en plus frequemment, ils mettent en oeuvre 

1 0 des systemes de gestion de bases de donnees relationnelles. 

Ces systemes sont bien adaptes au stockage de donnees comportant des 
parties en nombre fixe et des parties en nombre variable, les parties en nombre fixe 
etant stockees dans une table principale et les parties en nombre variable etant 
chacune stockees dans une table annexe de la base de donnees. En general, ces 

1 5 systemes pefmettent en outre de cascader les donnees en nombre variable, e'est-a-dire 
que chaque ensemble ou enregistrement de donnees en nombre variable peut etre & 
son tour associe a d'autres donnees en nombre variable. En outre, ces systemes de 
gestion de base de donnees offrent habituellement des possibility ^interrogation 
sophistiquee, et de bonnes performances, m&ne sous forte charge. 

20 En l'absence de systemes efficaoes de gestion de bases de donnees orientes 

objets, il est tentant d'utiliser les systemes de gestion de bases de donnees 
relationnelles du commerce pour la gestion et le stockage ou la gestion d'objets. 
Toutefois, ces systemes sont mal adaptes a la gestion d'objets. En effet, dans ces 
systemes traditionnels, les donnees sont stockees dans des tables d'ensembles de 

25 donnees ayant une structure fixe, ces ensembles de donnees etant constitues de 
donnees simples. Cela signifie en particulier qu'il n'est pas possible d'imbriquer ou 
d'emboiter des ensembles de donnees a l'interieur d'un autre, memo si les ensembles 
de donnees sont en nombre fixe. 

Ce dernier point pose probleme pour la gestion d'objets en ce que 

30 i'emboftement d'objets les uns a l'interieur des autres est le fondement mSme de la 
gestion de donnees orientee objets. U est theoriquement possible de resoudre ce 
probleme automatiquement en mettant "a plat" la structure de l'objet, e'est-a-dire, en 
considerant que tous les elements de sous-objets inclus dans un objet principal sont 
en fait des elements de l'objet principal. 

3 5 Cela introduit un nouveau probleme en ce que les noms d' elements contenus 

dans des sous-objets distincts d'un meme objet peuvent parfaitement etre identiques 
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et que les noms d'el6ments dans un meme objet doivent necessairement etre distincts, 
pour d'evidentes raisons de non-ambigulte. Ce nouveau probleme peut a son tour etre 
resolu automatiquement en incluant le nom du sous-objet contenant dans le nouveau 
nom "a plat" d'un element d'un sous-objet. En pratique, cela revient a ajouter les 
5 noms de tous les objets contenants a Mement contenu pour obtenir un nom "a plat" 
non ambigu. 

Malheureusement, cette technique conduit rapidement a des noms "a plat" 
ayant une longueur de nom depassant les limites autorisees par les systemes de 
gestion de bases de donnees, meme pour des 61ements peu imbriques, du fait que ces 

10 systemes imposent des limites de l'ordre de quelques dizaines de caracteres sur la 
longueur des noms des donnees simples stockees dans une table. Cette nouvelle 
difficult^ est habituellement resolue en tronquant le nom "a plat" obtenu a la 
longueur permise par le systeme. Toutefois, ce procede conduit usuellement a des 
noms "a plat" dupliques. 

15 La resolution definitive de ce probleme implique habituellement une 

intervention manuelle d'un opeiateur humain, qui definit lui-meme les noms a utiliser 
dans le systeme de gestion de base de donnees, pour chaque el6ment d'objet 
imbrique. De faeon evidente, cette intervention manuelle est sujettea erreur et elle 
est couteuse en temps humain. 

20 Par ailleurs, la technique consistant a utiliser une table annexe pour chaque 

partie en nombre variable d'un objet conduit rapidement a des performances 
deplorables lorsqu'un objet comporte de nombreuses parties en nombre variable, 
comme c'est souvent le cas en pratique. En effet, chaque acces a un objet stocke dans 
la base de donnees requerra un acces a la base de donnees pour la table principale 

25 plus autant d'acces a la base de donnees qu'il y a de tables annexes, c'est-a-dire, de 
parties d'objets en nombre variable dans un objet. Si l'objet comporte, comme il est 
frequent, cinq ou dix parties en nombre variable, le nombre d'acces a la base de 
donnees sera multiplie par cinq ou dix par rapport a un objet n'ayant pas de parties 
variables, ce se traduit par une degradation des performances dans un meme rapport. 
' 30 Cette degradation peut devenir critique dans les systemes de stockage de 

donnees tres sollicites, tels que les serveurs Internet, car il n'estpas toujours possible 
de dupliquer les serveurs pour repartir la charge, en particulier lorsque les donnees 
presentes sur un serveur peuvent etre modifiees. En outre, cela augmente dans les 
memes proportions la fragilite du systeme de stockage vis-a-vis d'une panne de 

35 courant ou de tout autre probleme systeme entrainant un an-8t inopine" du systeme 
informatique Mbergeant la base de donnees. 
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II existe done un besom pour un procecte qui permette d'adapter les systemes 
de gestion de base de donnees relationnelles existants aux sp6cificites du stoclcage 
d'objets, en gerant automatiquement les limites imposes sur la longueur des noms 
des donn6es simples stockees dans les tables et limitant le nombre de tables annexes 
5 utilisees pour conserver de bonnes performances au systeme de stoclcage d'objets 
dans son ensemble. 

La presente invention a done pour objet de proposer un precede" et un 
systeme qui permettent de limiter a une table principale et une table annexe le 
nombre de tables necessaire pour stocker les donn6es simples en nombre fixe et 
1 0 variable d'une collection d'objets informatiques presents dans un systeme de stoclcage 
de donnees. 

La presente invention propose done un procede de stockage d'objets 
informationnels ou objets dans une base de donnees relationnelle stockee dans un 
ordinateur serveur, ladite base de donnees relationnelle etant constituee de tables, 

15 chaque table etant constituee d'un tableau d'ensembles de donnees simples, lesdits 
ensembles ayant la meme structure de donnees dans une meme table, chaque donnee 
simple d'une table etant designee par un identifiant unique dans ladite table, un objet 
&ant constitu6 d'une ou plusieurs donnees simples pouvant toe stockees dans une 
table de ladite base de donnees, et/ou d'un ou plusieurs objets emboites dans ledit 

20 objet, ledit emboftement pouvant 6tre realise' sur un nombre quelconque de niveaux 
pour realiser un objet, un objet embolte' ou vine donnee simple 6tant dit localement en 
nombre fixe s'il ou elle apparaft exactement une fois dans 1'objet le ou la contenant 
immediatement et etant dit localement en nombre variable dans le cas contraire, une 
donnee simple apparaissant a un niveau quelconque dudit objet <§tant dite 

25 globalement en nombre fixe si elle est localement en nombre fixe et si tous les objets 
la contenant sont localement en nombre fixe, une donnee simple apparaissant a un 
niveau quelconque dudit objet 6tant dite globalement en nombre variable si elle est 
localement en nombre variable ou si l'un quelconque des objets la contenant est 
localement en nombre variable, lesdites donnees globalement en nombre fixe d'un 

30 objet a stocker 6tant stockees dans un ensemble de donnees principal stock6 dans une 
table principale de ladite base de donnees, lesdites donnees simples globalement en 
nombre variable dudit objet a stocker etant stockees dans une ou plusieurs tables 
annexes de ladite base de donnees, qui a pour caracteristique le fait que, lorsqu'elles 
existent, les donnees simples globalement en nombre variable desdits objets sont 

35 stockees dans une unique table annexe de ladite base de donnees, le proced6 creant 
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un ou plusieurs ensembles de donnees annexes pour stocker lesdites donnees simples 
globalement en nombre variable dans ladite unique table annexe. 

Dans ce proc£d6, chacun desdits un ou plusieurs ensembles annexes 
eventuellement stockes dans ladite unique table annexe peut comporter en outre un 
5 ensemble d'indicateurs booleens, chaque indicateur booleen etant associe a une 
donnee particuliere desdites donnees simples globalement en nombre variable 
stockees dans ledit ensemble annexe, ledit indicateur booleen indiquant si ladite 
donnee simple globalement en nombre variable associee est d6finie ou non dans ledit 
ensemble annexe. Dans ce cas, certains desdits indicateurs booleens dudit ensemble 

10 d'indicateurs booleens pourront etre communs a plusieurs donnees simples 
globalement en nombre variable lorsque lesdites donnees simples sont localement en 
nombre fixe dans un m£me objet les contenant immediatement 

De preference, ledit ensemble principal associe au dit objet a stocker 
comportera une donnee permettant d'identifier de fa$on imique ledit ensemble 

15 principal dans ladite table principale. De plus, ladite donnee unique pourra etre 
unique dans ledit ordinateur serveur, et avantageusement, ladite donnee unique 
stockee dans ledit ensemble principal associe au dit objet a stocker sera en outre 
stockee dans chacun des ensembles annexes associes au dit objet a stocker, pour 
permettre la mise en relation dudit ensemble principal et du ou desdits ensembles 

20 annexes eventuels associes au dit objet a stocker. 

De facon avantageuse, ladite donnee unique pourra etre constitute du nom 
logique de l'ordinateur serveur sur ledit reseau, du numero de table de ladite table 
principale dans ladite base de donnees et du num6ro d'ensemble de donnees dudit 
ensemble principal dans ladite table principale, ledit nom logique de l'ordinateur 

25 serveur etant unique sur ledit reseau, ladite base de donnees etant unique sur ledit 
ordinateur serveur, ledit numero de table de ladite table principale etant unique dans 
ladite base de donnees et ledit numero d'ensemble de donnees dudit ensemble 
principal etant unique dans ladite table principale. 

Dans le procede, deux objets a stocker pourront etre dits de meme type s'ils 

30 sont constitues de donnees simples et d'objets emboites de meme type, deux objets de 
meme type ayant en commun un meme identifiant et les donnees simples et/ou les 
objets emboites se correspondant a un niveau quelconque desdits objets de meme 
type ayant en commun un meme identifiant, unique dans l'objet les contenant 
immediatement. 

35 Dans ce cas, le procede" pourra creer un identifiant global pour tous les 

objets de meme type et pour toutes les donnees simples se correspondant a un niveau 



. ) 

WO 02/03245 



) 

PCT7FROO/01902 



5 

quelconque desdits objets de m&ne type, ledit identifiant global etan.t ledit identifiant 
commvm pour lesdits objets de m6me type, et ledit identifiant global etant obtenu, 
pow chacune desdites donnees simples se correspondant, par la concatenation des 
identifiants, dans les objets les contenant immediatement, de tous les objets 
5 contenant ladite donnee simple, et de l'identifiant de ladite donnee simple dans l'objet 
la contenant immediatement. 

En outre, le nombre de caracteres de cet identifiant global pourra etre 
tronque au nombre de caracteres permis par ladite base de donnees pour l'identifiant 
d'une donne'e stockSe dans une table de ladite base de donnees. Egalement, nne 
10 ambiguite pouvant apparaitre du fait de ladite troncature pourra 6tre r6solue en 
effectuant les Stapes consistant a : 

- remplacer le demier caractere alphabetique de l'identifiant global par le 
chiffre zero, ainsi que les eventuels chiffres )e suivant ; 

augmenter d'une unite le nombre consume" par l'ensemble des chiffres 
1 5 apparaissant a la fm dudit identifiant global jusqu'a ce que l'ambigu'fte 

disparaisse ou que les chiffres a la fin dudit identifiant global soient 
entierement constitues de chiffres neuf ; 

- repeter les Stapes precedentes depuis le debut lorsque les chiffres 
apparaissant a la fin dudit identifiant global sont entierement constitues 

20 de chiffres neuf a Tissue de l'etape precedente. 

Dans le precede" de l'invention, les objets stocke's dans la base de donnees 
pourront 6tre recus ou transmis pai' Fordinateur serveur via un r6seau infoimatique de 
type Internet. 

De pr6f6rence, les donnees simples constituant lesdits objets (6) stockes 
25 dans ladite base de donn6es seront de type texte, et avantageusement, lesdites 
donnees simples de type texte seront des donnees ecrites en langage XML. De plus, 
lesdites donnees Writes en langage XML pourront etre conformes a une description 
de type XML Schema. 

En outre, un ensemble de donnees au format XML pourra She obtenu par 
30 une traduction automatique de ladite description, ledit ensemble de donn6es et un 
ensemble de donn6es complementaire 6tant a leur tour traduits automatiquement en 
langage SQL pour definir et gerer la structure de la base de donnees, et pour controler 
les 6changes de donn6es avec ladite base de donnees. 

Par ailleurs, dans le procede" de l'invention, une partie des donnees simples 
35 des objets recus par ledit reseau de type Internet pourra Stre supprimee a l'aide d'un 
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patron, ou module, d'objet ecrit en langage XML, pour interdire la modification 
desdites donn6es simples via ledit reseau. 

Egalement, une partie des donnees simples des objets transmis via ledit 
reseau pourra etre supprimee a l'aide d"un patron d'objet ecrit en langage XML pour 
5 limiter la transmission sur ledit reseau a certaines donnees simples desdits objets. De 
plus, la suppression d'une partie des donnees simples contenues dans les objets 
permettra en outre d'optimiser les requeues a ladite base de donnees. 

L'invention propose en outre un systeme de stockage d'objets 
informationnels ou objets, dans une base de donnees relationnelle stockee par un 
10 ordinateur serveur, qui a pour caracteristique le fait qu'il met en ceuvre le proce4e 
selon l'une quelconques des revendications prec^dentes. 

Un mode de realisation preferentiel de l'invention va maintenant etre decrit, 
atitre d'exemple seulement, en se referant aux dessins annexes, dans lesquels : 

- la figure 1 est le schema fonctionnel du mode de realisation prefere" du 
1 5 procede de stoclcage d'obj ets selon la prSsente invention ; 

- la figure 2 est un schema montant l'utilisation d'une table annexe unique 
pour les ensembles en nombre variable dans le mode de realisation 
prefere du procede de rinvention sur un cas d'exemple ; 

- la figure 3 est un schema montant l'utilisation d'un ensemble de tables 
20 annexes pour les ensembles en nombre variables dans la technique 

anterieure, sur le meme cas d'exemple que celui de la figure 2. 
Pour permettre la comparaison, un exemple de stockage d'objet de la 
technique anterieure sera egalement d6crit. Dans les deux cas, on supposera, de fa9on 
non restrictive, que le systeme de gestion de base de donnees relationnelle, ou 
25 SGBDR, utilise est mis en ceuvre a l'aide du langage standard Stmctured Query 
Language, ou SQL. 

Par ailleurs, pour faciliter la comprehension, on decrira les operations de 
stockage concemant un objet 6 d'exemple, tel qu'une entree dans un annuaire 
comportant les iirformations suivantes : 
30 Entree annuaire : 

Norn, sur 40 caracteres : OTOOBE 
Telephone, sur 15 caracteres : +33(0)1 44 34 85 03 
Telecopie, sur 15 caracteres : +33(0)1 44 34 85 01 
Adresse : 

35 Rue, sur 40 caracteres : 3bis, rue du Docteur-Foucault 

Ville, sur 40 caracteres : 92000 NANTERRE 
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Adresse : 

Rue, sur 40 caracteres : 34, bd Haussmann 

Ville, sur 40 caracteres : 75009 PARIS 
Contact, sur 40 caracteres : M. Laurent QUEREL 
5 Contact, sur 40 caracteres : M. Jean-Francois QUENTIN 

Contact, sur 40 caracteres : M. Gilles ANDRE 

Dans cette entree, les donnees "Adresse" et "Contact" sont supposees 
pouvoir figurer en nombre variable dans ledit objet 6 "Entree anmiaire", pour prendre 
en compte le fait qu'une- entreprise peut comporter plusieurs etablissement et 

10 plusieurs personnes a contacter. Pour la clart£ de l'expos6, le nombre des donnees en 
nombre variable a 6te limits a deux dans cet exemple, mais ce nombre ne limite en 
rien la portee du proceed de la presente invention. 

Les objets informationnels, ou objets, dont la structure de donnees n'est pas 
fixe, permettent de prendre en compte ce type de donnees en nombre variable,. ce qui 

1 5 fait toute la puissance de l'approche objet par rapport a une approche traditionnelle on 
la structui'e des donnees est fixe, et dans laquelle il est done necessaire de prevoir a 
l'avance un nombre maximal d'occurrences pour chaque donnee, an risque d'un cote 
de bloquer de fa9on gSnante un cas particulier oil un nombre. d'occurrences plus 
important que celui prevu serait necessaire, et d'un autre cote, de gaspiller 

20 inutilement de la place de stockage dans le cas general pour quelques cas particuliers 
peu fr6quents. 

Malheureusement, les systemes de gestion de base de donnees classiques 
actuels ne permettent pas directement le stockage d'objets, e'est-a-dire de structures 
de donnees permettant l'emboitement de sous-structures de donndes et des 
25 occurrences multiples pour les elements de ces structures, ce qui necessite un 
traitement particulier des donnees de l'objet 6 "Entree annuaire" pour pouvoir le 
stocker dans' la base de donnees 2. 

Dans la technique anterieure, ce traitement consiste a separer les donnees en 
nombre fixe "nom", "telephone", "telecopie" et les donnees en nombre variable "rue", 
30 "ville" en stockant les donnees en nombre fixe dans une premiere table principale 3, 
et en stockant les donnees, ou ensembles de donnees, en nombre variable dans autant 
d'autres tables annexes qu'il existe de donnees, ou d'ensembles de donnees, en 
nombre variable dans l'objet 6. 

Dans la technique anterieure, l'objet 6 de l'exemple precedent est alors 
35 stocke" sous la forme indique a la figure 3, dans laquelle : 
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- la table 3 est la table principale stockant les ensembles 31 de donnees en 
nombre fixe constitues des donnees simples "cle" 11, "nom" 12, 
"teI6phone" 13 et "telecopie" 14 ; 

- la table 4 est une premiere table annexe stockant les ensembles 41 
5 constitues de la donnee simple "cle" 11 et de la donn6e en nombre 

variable "adresse", c'est-a-dire, des donnees simples "rue" 15 et "ville" 
16; 

- la table 5 est une seconde table annexe stockant les ensembles de 
donnees constitues de la donned "cle" 11 et de la donnee en nombre 

10 variable "contact" 17. 

Plus precisement, dans l'exemple ci-dessus, la donnee "nom" ayant pour 
valeur "OTOOBE" sera stocks en 12, la donnee "telephone" ayant pour valeur 
"+33(0)1 44 34 85 03" sera stockee en 13, la donnee "telecopie" ayant pour valeur 
"+33(0)1 44 34 85 01" sera stockee en 14, la donnee "rue" du premier sous-objet 

15 "adresse", ayant pour valeur "3bis, rue du Docteur-Foucault", sera stockee en 15i, la 
donnee "ville" du premier sous-objet "adresse", ayant pour valeur "92000 
NANTERRE", sera stockee en 16u la donnee "rue" du second sous-objet "adresse", 
ayant pour valeur "34, bd Haussmann", sera stockee en 15 2 , la donnee "ville" du 
second sous-objet "adresse", ayant pour valeur "75009 PARIS", sera stockee en 16 2 , 

20 la premiere donnee "contact", ayant pour valeur "M. Laurent QUEREL", sera stockee 
en 17i, la seconde donnee "contact", ayant pour valeur "M. Jean-Francois 
QUENTIN", sera stockee en 172 et la troisieme donnee "contact", ayant pour valeur 
"M. Gilles ANDRE", sera stockee en 17 3 . 

La dorm6e "cle" 1 1 apparaissant dans les trois tables 3, 4 et 5 est la cle 

25 primaire de ces tables, et son utilisation sera decrite plus loin. 

Pour pouvoir utiliser ces donnees, il faut au prealable definir les tables 3, 4 
et 5 dans la base de donnees 2, ainsi que les diverses donnees stockees dans ces 
tables 3, 4 et 5. 

Dans la technique anterieure, pour creer la table 3, un operateur devait 
3 0 typiquement indiquer manuellement au SGBDR une instruction SQL du type : 
CREATE TABLE "EntreeAnnuaire_main" ( 
cle INTEGER, 
nom VARCHAR(40), 
telephone VARCHAR(1 5), 
35 telecopie VARCHAR(15), 

PRIMARY KEY (cle)) 
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Dans cette instruction, la rubrique "EntreeAnnuaire_main" indique le nom, 
librement choisi par l 1 operateur sous reserve d'unicit6, de la table principale 3, et une 
rubrique "VARCHAR(n)" indique une chaine de caracteres de longueur variable et 
de longueur maximale n. La donnee "cle" 1 1 est la cle priniaire evoquee ci-dessus et 
5 qui sera decrite plus loin, et la rubrique "PRIMARY KEY(cle)" indique precisement 
au systeme que cette donnee "cle" 1 1 est la cleprimaire. 

De m&tne, dans la technique anterieure, pour creer les tables 4 et 5, un 
operateur devait typiquement indiquer manuellement au SGBDR des instructions 
SQL du type : 

1 0 CREATE TABLE "EntreeAnnuaire_l " ( 

cle INTEGER, 
rue VARCHAR(40), 
villeVARCHAR(15), 
PRIMARY KEY (cle)) 

15 et: 

CREATE TABLE "EntreeAnnuaire_2" ( 
cle INTEGER, 
contact V ARCHAR(40), 
PRIMARY KEY (cle)) 
20 dans lesquelles les rubriques "EntreeAnnuaire_r' et "EntreeAnnuaireJJ" sont les 
noms respectifs, librement choisis, des tables annexes 4 et 5. 

En outre, l'operateur devait definir egalement manuellement les donnees 
indexees, c'est-a-dire les donnees dont le contenu pourra permettre de retrouver une 
entree de l'annuaire, au moyen ^instructions SQL du type : 
25 CREATE INDEX TndexNom" ON "EnteeeAimuaire_main" (nom) 

qui indique au SGBDR de faire en sorte qu'une entree d'annuaire puisse 6tre 
retrouvee par le contenu de la rubrique "nom" de la table principale 3 
"EntreeAnnuairejmain" . 

De plus, dans le cas d'objets 6 comportant de nombreux niveaux 
30 d'emboitement et de nombreuses donnees en nombre variable comme c'est souvent le 
cas en pratique, le nombre de tables annexes etait eleve, et la numerotation ou la 
denomination des tables annexes etait beaucoup plus complexe que celle present6e 
dans l'exemple prdceclent. A nouveau, cette numerotation ou cette denomination 
ndcessitait une intervention manuelle d'un operateur, avec les risques d'erreur 
3 5 inbirents a toute operation manuelle. 
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En se referant aux figures 1 et 2, on va maintenant decrire le procdde de 
stockage selon le mode de realisation pr6fere de 1'invention, qui est mis en osuvre par 
divers modules de programmes globalement denomm^s Collective Operating System 
ou COS dans ce document. 
5 En revenant a 1'exemple precedent, le proc^de" de l'invention gere l'ensemble 

31 de donnees simples en nombre fixe "cle" 11, "noin" 12, "telephone" 13, et 
"telecopie" 14 dans la table principale 3 de la m§me maniere que dans la technique 
anterieure, c'est-a-dire en utilisant directement les primitives adequates du SGBDR 
utilise. 

10 Par - contre, la gestion des donnees simple en nombre variable est effectuee a 

l'aide d'une unique table 7, au lieu des tables 4 et 5. Pour cela, le proceMe de 
l'invention stocke la premiere occurrence d'une donnee simple en nombre variable 
dans un premier ensemble de donates 71] de la table 7, la seconde occurrence d'une 
donnee simple en nombre variable dans un second ensemble de doiuiies 712 de la 

15 table 7, la troisieme occurrence eventucllc d'une donnee simple en nombre variable 
dans un troisieme ensemble de domi6es 71 3 , etc.. On voit alors que la structure de 
donnees de la table 7, c'est-a-dire la structure des ensembles de donnees 71, doit 
necessairement comporter au moins l'union des donnees simples en nombre variable 
dans un objet 6. 

20 Comme dans la technique anterieure, la donnee "cle" 1 1 apparaissant dans 

les deux tables 3 et 7 est la cle" primaire de ces tables, et son utilisation sera decrite 
plus loin. 

En revenant a 1'exemple precedent, le procede stocke done la donn6e 
premiere occurrence de la donnee simple "rue" de l'objet 6 dans 1'emplacement 15i de 

25 {'ensemble 71 1 de la table 7, il stocke la premiere occurrence de la donnee "ville" 
dans 1'emplacement 16] de l'ensemble 71 1 de la table 7, il stocke la seconde 
occurrence de la donnee "rue" dans 1'emplacement 152 de l'ensemble 71 2 , il stocke la 
seconde occurrence de la donnee "ville" I62 dans 1'emplacement I62 de l'ensemble 
7h, il stocke la premiere occurrence de la donnee "contact" 17i dans 1'emplacement 

30 17i de l'ensemble 71 1, il stocke la seconde occurrence de la donnee "contact" 17 2 
dans 1'emplacement 172 de l'ensemble 712, et il stocke la troisieme occurrence de la 
donnee "contact" 173 dans 1'emplacement 17 3 de l'ensemble 7I3. 

Toutefois, on voit dans ce qui precede que les emplacements correspondants 
aux donne'es simples "rue" et "ville" aux emplacements 153 et 16 3 dans l'ensemble de 

35 donnees simples 71 3 ne sont pas remplis, ce qui est du au fait qu'il riy a que deux 
ensembles de donnees en nombre variable "rue" et "ville", et qu'il y a trois donne'es 
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en nombre variable "contact". Cela pose un probleme en ce sens que si les ensembles 
de donnees simples 71 u 7\ 2 , 71 3 6taient stocks en l'etat dans la base de donnees, 
Tinformation concemant quels emplacements sont remplis et quels emplacements 
sont vides serait longue et difficile a determiner. II serait en effet necessaire de tester 
la nullit6 des colonnes de l'ensemble de ces donnees simples nombre variable pour 
determiner 1'absence ou la presence de ces donnees en nombre variable. 

Pour resoudre ce probleme, le procede selon I'invention reservera en outre, 
dans chaque ensemble 71, des emplacements de donnees pour stacker cette 
information de presence ou d'absence pour chaque donnee en nombre variable dans 
cet ensemble 71. 

En pratique, dans le cas de donnees simples en nombre fixe, telles que "rue" 
et "ville" associees dans un meme sous-objet contenant tel que "adresse", les donnees 
simples en nombre fixe associees seront toujours presentes ou absentes 
simultanement, ce qui signifie que le procede pourra optimiser le nombre 
d'indicateurs en ne stockant qu'un seul indicateur par ensemble de donnees en 
nombre fixe associees. 

Dans ces conditions, lors de la creation de la table 7, le procede" ajoute dans 
la structure de donnees de la table 7, c'est-a-dire dans chaque ensemble 71, une 
donnee booleenne pour chaque ensemble de donnees en nombre variable dans l'objet 
6. Dans l'exemple decrit, l'ensemble de donnees simples 72 constitue des donnees 
simples booleennes 20 et 21 est ainsi ajoute a chaque ensemble 71, la donnee 
booleenne 20 indiquant la presence, dans l'ensemble 71 considere, de l'ensemble 
constitue des donnees simples "rue" 15 et "ville" 16, et la donnee booleenne 21 
indiquant la presence, dans l'ensemble 71 considere de la donnee "contact" 17. 

Ainsi, les informations de presence ou d'absence des donnees ou des 
ensembles de donnees en nombre variable seront conservees lors de Tecriture d'un 
objet 6, et le proc&te pourra utiliser ces informations lors des relectures ulterieures, 
pour reconstituer conectement l'objet 6 tel qu'il etait au moment de son 
enregistrement. 

On notera qu'avec le proced6 de I'invention, le nombre d'ensembles de 
donn6e presents dans 1'unique table annexe est egal au maximum des nombres des 
donnees en nombre variable dans l'objet 6, alors que ce nombre d'ensembles de 
donnees dans les tables annexes est egal a la somme des nombres de donnees en 
nombre variable de l'objet 6 dans la technique anterieure, c'est-a-dire un nombre 
toujours plus eleve. 



) 



WO 02/03245 PCT/FROO/01902 

12 

Par ailleurs, dans le mode de realisation preferentiel, le proced6 est utilise 
pour stocker des objets 6 ecrits en langage XML qui sont conformes a une 
description 92 de type XML Schema, ce qui signifie en particulier que cette 
description est elle-mSme ecrtte dans le langage XML. 

Cette description 92, denommee COSSchema dans le mode de realisation 
preferentiel, decrit la structure de donnees des objets 6. L'intergt de cette description 
XML Schema 92 est de constituer une definition de reference unique pour la 
structure des objets 6, modele qui sera utilise chaque fois qu'il sera necessaire de 
verifier la structure ou la validite des objets 6. 

Dans le mode de realisation preferentiel, un certain nombre de definitions 
d'objets utilisees dans 2e schema COSSchema 92 sont derivees a partir de definitions 
stockees dans un autre schema XML Schema 91, denomme" COSCoreScheraa, 

L'interet de cette approche est de permettre au COS d'uniformiser les 
d&Bnitions de certains objets en leur dormant une base commune, et de pouvoir 
eventuellement effectuer un certain, nombre de travaux, cn particulier de 
maintenance, de facon homogene sur ces objets. Par exemple, s'il s'avere necessaire 
d'introduire une nouvelle donnee simple ou de modifier une donnde simple existante 
dans un type de base defmi dans le COSCoreSchema, il ne sera pas necessaire de. 
reproduire la nouvelle donnee simple ou la modification dans tous les objets bases 
sur ce type, et la modification sera implicitement reproduce via la seule reference au 
type de base. Ainsi, les risques d'erreur au niveau de la structure des objets COS 
seront r6duits d'autant, et la maintenance de ces objets s'en trouvera facilitee, 

En revenant h l'exemple d'entree d'annuaire vue precedemment, dans le 
mode de realisation prefere de l'invention, celle-ci sera constituee d'un objet 6, se 
presentant en langage XML sous la forme suivante : 
<entree_annuaire> 

<nom>OTOOBE</nom> 

<telephone>+33(0)l 44 34 85 03</telephone> 

<telecopie>+33(0)l 44 34 85 01<ytelecopie> 

<adresse> 

<rue>3bis, rue du Docteur-Foucault</rue> 
<ville>92000NANTERRE<yville> ; 
</adresse> 

<adresse> i 
<rue>34 5 bd Haussmann</rue> 
<ville>75009 PARIS</ville> 
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</adresse> 

<contact>M. Laurent QUEREL</contact> 
<contact>M. Jean-Francois QUENTIN</contact> 
<contact>M. Gilles ANDRE<ycontact> 
5 </entree_annuaire> 

Cet objet sera typiquement conforms a im fragment du COSSchema, qui est 
de type XML Schema, se pr&entant sous la forme suivante : 
<type name- 'entree_annuaire"> 

<element name="nom" minOccuis- ' 1 "> 
10 <datatype source- 'string"> 

<length value="407> 
</datatype> 
</element> 

<element name="telephone" minOccurs- T'> 
15 <datatype source- 'string''> 

<lengthvalue="157> 
■ </datatype> 
</element> 

<element name-'telecopie" irrM)ccurs='T'> 
20 <datatype source- "string"> 

<engthvalue="157> 
</datatype> 
</element> 

<fype name- 'adresse" minOccurs-" 1 " maxOccurs="*"> 
25 <eiementname="rue" minOccurs- T'> 

<datatype source="string"> 
<length value="40"/> 
</datatype> 
</element> 

3 0 <element name-'ville" minOccurs=" 1 M > 

<datatype source="string"> 
<length va!ue="40"/> 
</datatype> 
</element> 
35 </type> 

<element name- 'contact" minOccurs-'O" maxOccurs-'*'^ 
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<datatype source= ; "st.-ing"> 
<lengmvalue="4u"/> 
</datatype> 
</elemem> 
5 </type> 

Dans cette definition XML Schema, le parametre 'minOccurs' d'une donnee 
simple ou d'un sous-objet embofte indique le nombre minimum de fois ou la donnee 
concerned apparatt dans l'objet immediatement contenant, et le parametre 
'maxOccurs' d'une donnee simple ou d'un sous-objet embotte indique le nombre 
10 maximum de fois ou la donnee concemee apparatt dans l'objet immediatement 
contenant. Par defaut, c'est-a-dire lorsque 'maxOccurs' n'apparaft pas, il est suppos6 
etreegala 1, 

La signification de 'maxOccurs- '*'" est que la donnee ou le sous-objet 
concerne peut apparame un nombre quelconque de fois dans l'objet immediatement 
1 5 contenant. 

Dans le mode de realisation prefere de l'invention, le procede utilise cette 
description au format XML, en association avec le procede de stockage d'objets dans 
seulement deux tables qui a ete decrit plus haut, pour gen6rer automatiquement des 
instructions SQL pour creer et gerer les donnees de la base de donnees 2 representant 

20 les objets stockes. 

Pour cela, le proc6de de l'invention part du COSSchema et il applique un 
certain nombre de regies pour obtenir un format XML Schema etendu, d6nomme 
XDB Schema, comparable a celui de l'exemple decrit ci-dessus. En effet, dans le 
COSSchema, la description des donnees est faite, de facon structuree, en se r6ferant a 

25 d'autres types pr&iefinis, tels que les types definis dans le COSCoreSchema ou a des 
types intermediaires defmis dans le COSSchema lukneme. Pour rendre utilisables 
dans le langage SQL utilise les informations presentes dans le COS Schema, le 
procede de l'invention, applique done a ce schema COS Schema un certain nombre 
de regies de traduction lui permettant de passer d'une representation comportant des 

3 0 types non simples a une representation ne comportant plus que des types simples, Le 
resultat de cette traduction constitue le schema XDB Schema. 

Toutefois, le schema XDB Schema obtenu prec6demment n'est pas suffisant 
a lui seul pour defmir completement la structure de l'objet 6 dans la base de donnees 
2 : en effet, il manque les informations permettant de defmir les donnees de l'objet 6 

35 qui seront indexees. Pom resoudre ce probleme, le procede de l'invention utilise un 
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schema XML 96 complementaire, denomme XDB Mapping, decrivant les donnees a 
indexer dans les tables stockant les donnees de l'objet 6. 

Ce sch6ma XDB Mapping 96 reprend la structure du schema COSSchema 
en la limitant aux donnees devant fane l'objet d'une indexation. Ainsi, dans l'exemple 
5 precedent ou la donnee "nom" devait e'tre iudexee, le fragment correspondant dans le 
XDB Mapping sera du type suivant : 
<type name="entree_annuaii"e"> 



10 ou larubrique "sql:indexname" indique le nom de l'index a. creer, ici "IndexNom", et 
oU la rubrique "sqhindexType" sert a indiquer, sous une syntaxe adequate, des 
parametres pour l'index a creer, tels que "ordre de tri croissant", "pas de distinction 
minuscules/majuscules", etc.. Ainsi, avec ce schema XDB Schema, le procede de 
l'invention possede toutes les informations utiles pour creer automatiquement dans la 

1 5 base de donnees 2 toutes les donnees necessaires poui' l'objet 6 k creer. 

Ensuite, le proced6 traduit ces schemas XDB Schema et XDB Mapping en 
instructions SQL a destination du SGBD g&ant la base de donnees 2. 

Toutefois, avant de pouvoir mener a bien cette operation, un autre probleme, 
lie aux possibility offertes par les objets, doit itre resolu. En effet, Tapproche 

20 orients objet permet a des donnSes simples, ou a des sous-objets, contenus dans des 
sous-objets distincts d'avoir le mdme identifiant, pourvu que cet identifiant soit 
unique dans le sous-objet, ou l'objet 6, les contenant imm^diatement, Cette 
possibility de noms dupliques dans des sous-objets differents interdit d'utiliser 
directement ces identifiants comme identifiants globaux de donn6es dans la base de 

25 donnees 2, car deux donnees distinctes d'une m6me table pourraient alors recevoir le 
m&ne identifiant, ce qui est interdit par tous les SGBDR existants. 

Pour resoudre ce probleme, le procede cree pour chaque donnee simple un 
identifiant global obtenu en prefixant l'identifiant de la donnee simple, tel qu'il 
apparait dans la rubrique 'name-'..."' de la definition de la donnee simple dans le 

30 schema XDB Schema, par la concatenation des identifiants, tels qu'il apparaissent 
dans les rubriques 'name-'...'" des definitions correspondantes du schema XDB 
Schema, de tous les sous-objets contenant, a une niveau ou un autre, la donnee 
simple considered. Ce procede leve 1'ambiguM qui pourrait apparartre, car du fait que 
les identifiants des donnees simples ou des sous-objets dans leurs objets 

35 immediatement contenant sont distincts, deux identifiants globaux obtenus de cette 
facon sont n^cessairement distincts globalement. 



<element name="nom" sql:indexname="IndexNom" 



sql:indexType : 



</type> 
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Ainsi, dans l'exemple ci-dessus, Videntifiant global de la donnee "nom" sera 
"nom" lui-meme, puisque la donnee simple "nom" n'est pas contenue dans un sous- 
objet ; par contre, Videntifiant global de la donnee "rue" contenue dans le sous-objet 
"adresse" sera "adresse_rue". 
5 Dans ce qui precede, on a indique" que les identifiants des donnees creees 

dans les tables 3 et 7 de la base de donnees 2 etait la concatenation des identifiants de 
la donnee et de tous les sous-objets la contenant dans Vobjet 6. Toutefois, cela pose 
probleme en ce que la longueur de ces identifiants est habituellenient lhnitee par les 
SGBDR classiques a une valeur assez basse, de l'ordre de quelques dizaines de 

10 caiacteres, et que, pour des objets comportant un niveau d'emboJtement meme 
moder6, cette limite est tres vite atteinte. 

Pour resoudre ce probleme, le procdde' de Vinvention tronque les identifiants 
prec^demment obtenus a la longueur permise par le SGBDR pour les identifiants de 
donnees d'une table. A Tissue de cette troncature, si Videntifiant global obtenu est 

1 5 deja present dans la table ou il devait etre cr66, le proc^de' de 1'invention realise les 
6tapes suivantes : 

1°/ le dernier caractere alphabetique de Videntifiant global prec^demment 
obtenu est remplace" par le chiffre "0", ainsi que tous les chiffres le suivant 
6ventuellement ; 

20 2°/ si Videntifiant global ainsi obtenu est encore present dans la table, le 

nombre constitue" par l'ensemble des chiffres appai'aissant a la fin de Videntifiant 
global est augmente d'une unite et Vetape 2 est repetee tant qu'un nombre entierement 
constitue de chiffres "9" n'a pas ete atteint ; 

3°/ si un nombre entierement constitue de chiffres "9" est atteint a Vetape 2, 
25 alors le procSde" retourne a Vetape 1 . 

Les Stapes 1°/ a 3°/ precedentes sont repefees jusqu'a ce qu'un identifiant 
global, nouveau dans la table consideree, soit trouve. 

Ainsi, le proced6 ci-dessus dealt permet de lever les ambiguftes, dans les 
identifiants globaux attribues aux donnees simples stockees dans la base de donnees 
30 2, qui peuvent apparartre du fait de la possibilite de duplication d'un identifiant de 
donnee ou de sous-objet dans des sous-objets distincts. 

En utilisant ce proc^de de generation d'identifiants globaux pour les donnees 
simples d'un objet 6, le proc^de relit alors en parallele le schema XDB Schema et 
XDB Mapping, et pour chaque nouveau type d'objet a creer 6 trouve dans le schema 
35 XDB Schema, il applique le procedd suivant : 
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- le procede cree alors dans la base de donnees une table principale 3 
portant le nom de I'objet 6, suivi du suffixe "_main", comportant une 
donnee "cle" 1 1 servant a identifier de facon unique dans la base de 
donnees un objet 6 ; ainsi, lorsqu'il rencontre dans le schema XDB 

5 Schema la definition : 

<type name="entree_annuaire"> 

</type> 

le proc6de" cree la table principale 3 "EntreeAnnuairejnain" 
1 0 correspondante par I'instruction SQL : 

CREATE TABLE "EntreeArmuairejnain' 1 (cle INTEGER, 
PRIMARY KEY (cle)) . 

- ensuite, le precede explore les definitions "<element ..>... </element>" du 
schema XDB Schema, XDB Schema et pour chaqne donnee simple 

1 5 rencontree, telles que "nom" ou "contact", il determine si cette donnee est 

en nombre fixe ou variable ; une donnee simple sera dite en nombre fixe 
si sa rubrique "maxOccurs" est absente de la definition et si cette donnee 
simple n'est pas contenue a un niveau quelconque dans un sous-objet en 
nombre variable, c'est-a-dire un sous-objet dont la rubrique "maxOccurs" 

20 serait presente et differente de la rubrique "minOccurs" dudit sous-objet ; 

une donnee sera dite en nombre variable dans le cas contraire, c'est-a-dire 
si elle n'est pas en nombre simple au regard de la definition precedente ; 

- lorsque le procede rencontre une donnee en nombre fixe telle que la 
donnee "nom" dans l'exemple ci-dessus, il ajoute cette donnee en nombre 

25 fixe dans la table principale 3 a 1'aide d'une instruction SQL telle que : 

ALTER TABLE "Enti'eeAnnuaire_main" ADD nom VARCHAR(40) 
dans laquelle l'identifiant global "nom" est obtenu par le precede" decrit 
plus haut, et dans laquelle la longueur "40" apparaissant dans la rubrique 
"VARCHAR" est reprise de la '<length value="...">' de la definition 

30 correspondante ; en outre, si le proc6de trouve dans le schema XDB 

Mapping une definition d'index portant sur la donnee qu'il vient de creer 
dans la table principale, le procede cree un index pour cette donnee a 
l'aide d'une instruction SQL adequate telle que : 
CREATE INDEX "IndexNom" ON "EntreeArmuahejrnain 1 ' (nom) 
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dans laquelle le noin de 1'index "IndexNom" est celui retrouve" dans la 
rubrique "sqhindexname" de la definition correspondante du schema 
XDB Mapping ; 

- lorsque le procede rencontre une donnee en nombre variable telle que la 
5 donnee "contact" dans l'exemple ci-dessus, il effectue les operations 

suivantes : 

■ s'il n'existe pas deja une table annexe 7 associee a cette table 
principale 3, il cree cette table annexe a l'aide d'une instmction SQL 
telle que : 

10 CREATE TABLE "EntreeAnnuaire_annex" (cle INTEGER, 

PRIMARY KEY (de)) 

■ dans laquelle la donnee "cle" est la donnee servant a identifier de 
facon unique un objet 6 dans la base de donnees 2 ; 

■ ensuite, le procede cree la donnee correspondante dans la seconde 
15 table, en lui associant, de la facon decrite precedemment, une 

donnee booleenne "presence", permettant de savoir si la donnee 
correspondante est presente ou non dans l'ensemble de donnees 71 
consider^ ; par exemple, pour la donnee en nombre variable 
"contact" 17, cette creation sera realisee a l'aide d'une instruction 
20 SQL telle que : 

ALTER TABLE "EntreeAnnuaire_annex" ADD contact 
VARCHAR(40), ADD presence_contact BOOLEAN 

■ dans laquelle l'identifiant global est obtenu par le procede decrit 
plus haut, et dans laquelle longueur "40" apparaissant dans la 

25 rubrique "VARCHAR" est reprise de la rubrique '<length 

value-"... ">' de la definition correspondante dans le schema XDB 
Schema ; 

■ dans le cas d'une donnee incluse dans un sous-objet comme la 
donnee "rue", l'identifiant global sera obtenu comme indique 

30 precedemment, et I'instmction SQL correspondante sera, par 

exemple : 

ALTER TABLE "EntreeAnnuaii-e^annex" ADD adresse_rue 
VARCHAR(40), ADD presence_adresse_rue BOOLEAN. 
Le procede repete les operations precedentes jusqu'a ce que toutes les 
35 definitions presentes dans le schema XDB Schema 61 aient et6 traitees. A Tissue de 
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ce traitement, le proced6 aura done cree automatiquement la structure d'objets 6 dans 
la base de donnees 2,- telle qu'elle 6tait decrite dans le schema COS Schema. 

Dans le mode de realisation de la presente invention, les aspects ci-dessus 
du procede" de l'invention sont imptementes dans un programme 90 denomme XBD 
5 Engine, et, contrairement a la technique anterieure, le proc6d6 de Tinvention permet 
de realiser la creation de nouveau type d'objet 6 dans la base de donnees 2 sans 
intervention manuelle d'un operateur, ce qui se traduit par un gain de temps tres 
appreciable et une diminution considerable du risque d'erreur, tant pour la creation 
que pour la modification, dans la base de donnees, de la structure d'un objet 6. 

10 Dans ce qui precede, on a decrit le proced6 de l'invention comme 

transformant le schema COSSchema, comportant des types predefinis, en un schema 
XML, le schema XDB Schema, ne comportant plus que des types de donnees simples 
tels qu'utilissSs par le SGBDR. Cela a 6t6 fait dans l'optique de l'utilisation d'un 
langage SQL de base, qui ne connait pas de types autres que ces types simples. 

15 Toutefois, dans le cas de l'utilisation d'un langage SQL evolu4 tel que le 

langage SQL 3, le proce^ de l'invention tirera naturellement parti des possibilit6s de 
typage offertes par ce langage en ne traduisant en types plus simples que les types ne 
pouvant pas 8tre "compris" directement par le langage SQL utilised Les types utilises 
par le COS Schema et pouvant e"tre traduits directement en types SQL, le seront a 

20 1'aide d'une instruction SQL adequate, telle que : 
CREATE TYPE ... 

Dans ce qui precede, on a decrit sur un exemple les 6tapes de creation d'un 
nouveau type d'objet 6 a stacker dans la base de donnees 2, tant dans la technique 
anterieure que dans le procede de l'invention. Les informations contenues dans 
25 COSSchema et XDBSchema seront bien evidemment reutilisees pour modifier la 
structure d'un objet 6 deja existant dans la base de donnees 2, apres que les 
modifications voulues y aient ete apportees. Cette modification de la structure d'un 
type d'objet 6 deja existant est en tout point similaire a. la creation precedemment 
decrite. Ainsi, par exemple, pour modifier une table 3|existante et y aj outer un 
30 nouveau champ, 1'instruction SQL utilisee, tant dans la technique anterieure que dans 
le procede de l'invention : 

CREATE TABLE ... 
sera remplacee, par exemple, par 1'instruction SQL : 

ALTER TABLE "EntreeAnnuaire_main" ADD telex VARCHAR(15), 
35 DROP telecopie 
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qui indique qu'une donnee "telex" sur quinze caracteres doit §tre ajoutee et que la 
donnee "telecopie" doit etre supprimee. 

De nieme, la suppression de l'index sur la donnee "nom" dans la table 3 se 
ferait, tant dans la teclinique anterieure que dans le procede de l'invention, par 
5 l'instruction SQL : 

DROP INDEX EntreeAnnuaireJndexNom 

Dans le cas du procede de l'invention, a nouveau ces modifications sont 
effectuees de facon automatique par le programme XDB Engine. 

Compte-tenu de ces similitudes, la modification de la structure d'un objet 6 
1 0 stocks dans la base de donnees 2 par le procede de l'invention ne sera pas decrite plus 
en detail. 

Dans ce qui suit, on va maintenant decrire le fonctionnement du procede 
selon la presente invention en comparaison avec la technique anterieure pour le 
stockage et la gestion des donnees en nombre variable d'un objet 6. 

15 En se refeiant aux figures 2 et 3, un systeme de stockage des donnees 

simples d'un objet 6, dans la technique anterieure comme dans le procede de 
['invention, est constitue d'un ordinateur 1 hebergeant une base de donnees 
relationnelle 2. Les ensembles de donnees simples d'une table principals telle que la 
table principale 3, ou ceux d'une table annexe telles que les tables 4, 5 ou 7, sont 

20 g6r6s a l'aide des fonctions offertes par le systeme de gestion de base de donnees 
relationnelle ou SGBDR, utilise" pour la gestion de la base de donnees 2. 

Ces fonctions comprennent au minimum une fonction d'ecriture ou de 
creation d'un ensemble de donnees simples dans une table, une fonction de lecture 
d'un ensemble de donnees simples depuis une table, une fonction de suppression d'un 

25 ensemble d'une table, et une fonction de recherche d'un ensemble par son contenu, la 
fonction de modification d'un ensemble pouvant She assimilee, pour la simplicity de 
l'expose, a une lecture de l'ensemble suivie d'une ecriture de l'ensemble modifie. Par 
consequent, cette fonction ne sera pas decrite davantage. 

Dans ce qui suit, on va comparer les performances, en termes de nombres 

30 d'ensembles de donnees echanges avec la base de donnees 2, respectivement pour la 
technique anterieure et le procede" de l'invention. 

En se refeiant a la figure 3, dans la technique anterieure, la base de donnees 
2 comporte une table principale 3 stockant les ensembles 3 1 de donnees simples en 
nombre fixe "nom" 12, "telephone" 13 et "telecopie" 14, et cette table principale est 

35 en relation avec deux tables annexes 4 et 5 contenant les ensembles 41 et 51 de 
donnees simples en nombre variable, respectivement les ensembles 41 constitues des 
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donnees simples "me" 15 et "ville" 16 pour la table annexe 4, et les ensembles 51 
constitues de la donnee "contact" 17 pour la table annexe 5. 

De facon classique, une donnee d'identification unique "cle" 11, presente 
dans les ensembles 31, 41 et 51 respectivement stockes dans les tables 3, 4 et 5, est 
5 utilisee pour mettre en relation, c'est-a-dire faire se referencer, la table principale 3 et 
les tables annexes 4 et 5. 

1°/ Ecriture d'un objet 6 dans la base de donnees 2 

L'ecriture, ou creation, d'un objet identifie par une valeur unique telle que 
1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
10 "telecopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et "contact" 17 en 
nombre variable, comportera classiquement les etapes suivantes : 

- denture de l'ensemble principal 3 1 constitue des donnees simples "cle" 
1 1, "nom" 12, "telephone" 13 et "telecopie" 14 dans la table 3 a l'aide de 
la fonction correspondante du SGBDR, en initiahsant la donnee "cle" 1 1 

15 a la valeur 1234 ; cela pourra 6tre realis6, par exemple, a l'aide d'une 

instruction SQL telle que : 

INSERT INTO "EntreeAnnuau-e_main" (cle, nom, telephone, telecopie) 
VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 
01") 

20 - ecriture de deux ensembles 41 constitues des donnees simples en nombre 

variable 15 et 16 a l'aide de la fonction correspondante du SGBDR, en 
im'tialisant dans chacun la donnee "cle" 11 ft," la valeur 1234, c'est-a-dire, 
denture des deux ensembles 41 1 et 41 2 constitues respectivement des 
donnees simples "cle" 11, "rue" 15 b "ville" 16 t dune part, et des donnees 

25 simples "cle" 11, "rue" 15 2 , "ville" 16 2 d'autre part; cela pourra etre 

rdalise, par exemple, par les instructions SQL ; 

INSERT INTO "EntreeAnnuaiie_l" (cle, rue, ville) VALUES (1234, 

"3bis, rue du Docteur-Foucault", "92000 NANTERRE") 

et: 

30 INSERT INTO "EntreeAnnuaire_l" (cle, rue, ville) VALUES (1234, "34, 

bd Haussmann", "75009 PARIS") 

- ecriture de trois ensembles 51 a l'aide de la fonction correspondante du 

SGBDR, en initialisant la donnee "cle" 11 a la valeur 1234, c'est-a-dire, 
ecriture des trois ensembles 51|, 51 2 et 51 3 constitues respectivement des 
35 donnees simples "cle" 11 et "contact" 17i pour le premier, des donnees 

simples "cle" 11 et "contact" 17 2 pour le second, et "cle" 11 et "contact" 
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I7i pour le troisieme ; cela pourra Stre realise, par exemple, par les 
instructions SQL : 

INSERT INTO "EntreeArmrjaire_2" (cle, contact) VALUES (1234, "M. 
Laurent QUEREL") 

5 INSERT INTO "EntreeAimuaireJ2" (cle, contact) VALUES (1234, "M. 

Jean-Francois QUENTIN") 
et: 

INSERT INTO "EntreeAiiniiaire_2" (cle, contact) VALUES (1234, "M. 
Gilles ANDRE") 

10 On constate que, dans la technique anterieure, on effectue done une 

operation d'ecriture pour stocker l'ensemble 31, deux operations d'ecriture pour 
stocker les ensembles 41, et trois ecritures pour stocker les ensembles 51, soit un 
total de six ecritures pour stocker l'ensemble des donnees correspondant a l'objet a 
stocker 6. 

1 5 27 Lecture d'un objet 6 dans la base de donnees 2 

La lecture d'un objet 6, ayant pour donn6e unique "cle" 11 une valeur 
donnee telle que 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associ6es aux donnees simples "rue" 15, "ville" 16 et 
"contact" 17 en nombre variable, se fera classiquement par les etapes suivantes : 
20 - lecture, a l'aide de la fonction correspondante du SGBDR, de l'ensemble 

principal 31, constitue des donnees simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donnee "cle" 11 a la valeur 
donnee 1234 ; cela pourra Stre realise, par exemple, a l'aide de 
l'instruction SQL : 

25 SELECT * FROM "EntreeAnnuaire„main" WHERE cle=l 234 

- lecture, l'aide de la fonction correspondante du SGBDR, de tous les 
ensembles 41 de la table 4 comportant la valeur 1234 dans leur donnee 
"cle" 11, e'est-a-dire, lecture des deux ensembles 41 1 et 41 2 constitues 
respectivement des donnees simples "cle" 1 1, "rue" 15i, "ville" 16i d'une 

30 part, et des donnees simples "cle" 11, "rue" 152, "ville" I62 d'autre part ; 

cela pourra etre obtenu, par exemple, a l'aide de l'instruction SQL ; 
SELECT * FROM "EntreeAnnuaire_l " WHERE cle=1234 
cette instruction retrouvera alors les deux ensembles de donnees 41 j et 
41 2 ; 

35 - lecture des ensembles 51 a l'aide de la fonction correspondante du 

SGBDR, en relisant tous les ensembles 51 de la table 5 comportant la 
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valeur donnee 1234 dans leur donuee "cle" 11, c'est-a-dire, lecture des 
trois ensembles 51 b 51 2 et 51 3 constitues vespectiveraent des donnees 
simples "cle" 11 et "contact" 17] pour le premier, des donnees simples 
"cle" 11 et "contact" 172 pour le second, et "ck" H et "contact" 17 t pour 
5 le troisieme ; cela pourra etre obtenu, par exemple, a 1'aide de 

instruction SQL : 

SELECT * FROM "EntreeAnnuaire_2" WHERE cle-1234 

cette instruction retrouvera alors les trois ensembles de donnees 5 1 1 , 5 1 2 

et 51 3 . 

10 De meme que pom' l'operation d'ecriture, on constate que, dans la technique 

antdrieure, on effectue done au total de six operations de lecture d'ensemble de 
donnees dans les tables 3, 4 et 5 pour relire l'ensemble des donnees correspondent a 
l'objet 6 arelire. 

3°/ Suppression d'un objet 6 dans la base de donnees 2 

15 La suppression d'un objet, constitue des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, ayant pour donnee "cle" 11 une valeur donnee, 
par exemple 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees shnples en nombre variable 
"rue" 15, "ville" 16 et "contact" 17, se composera classiquement des 6tapes 

20 suivantes : 

- suppression de l'ensemble principal 31 ayant pour donnee "cle" 11 la 
valeur donnee 1234 a l'aide de la fonction correspondante du SGBDR ; 
cela pourra ftre realise, par exemple, a l'aide de Instruction SQL : 
DELETE FROM "EntreeAnnuaire_main" WHERE cle=1234 

25 - suppression des ensembles 41 ayant comme donnee "cle" 1 1 la valeur 

donnee 1234 a l'aide de la fonction correspondante du SGBDR, e'est-a- 
dire, suppression des deux ensembles 4 1 j et 41 2 constitues 
respectivement des donnees simples "cle" 11, "rue" I5i, "ville" 16i d'une 
part, et des donnees simples "cle" 11, "rue" 15 2 , "ville" 16 2 d'autre part ; 

30 cela pourra etre realist, par exemple, a l'aide de ^instruction SQL : 

DELETE FROM "EntreeAnnuaireJ" WHERE cle=1234 

- suppression des ensembles 51 ayant comme donnee "cle" 11 la valeur 
donnee 1234 a l'aide de la fonction correspondante du SGBDR, e'est-i- 
dire, suppression des trois ensembles 51 1, 51 2 et 5I3 constitues 

35 respectivement des donnees simples "cle" 11 et "contact" 17i pom le 

premier, des donnees simples "cle" 11 et "contact" 17 2 pour le second, et 
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"cle" 11 et "contact" 17 3 pour le troisi6me ; cela pourra Stre realise, par 
exemple, a l'aide de l'instruction SQL : 
DELETE FROM "EntreeAnnuaire_2" WHERE cle=1234 
De meme que pour les operations d'ecriture ou de lecture, on constate que, 
5 dans la technique anterieure, on effectue au total de six operations de suppression 
d'ensemble de donnees dans ies tables 3, 4, et 5 pour supprimer l'ensemble des 
donnees correspondant a l'objet 6 a supprimer. 

4°/ Recherche d'un objet 6 dans la base de donnees 2 
Toujours dans la technique anterieure, la recherche d'un objet ayant, par 
10 exemple, pour donnee 12 "nom" la valeur "OTOOBE", et comportant un ensemble 
31 de donnees simples en nombre fixe "nom" 12, "telephone" 13, "telecopie" 14 
associees aux donnees simples "rue" 15, "ville" 16 et "contact" 17 presentes dans les 
ensembles 41 et 51, sera constitute classiquement des etapes suivantes : 

- recherche, a l'aide de la fonction correspondante du SGBDR, de 
15 l'ensemble principal 31, constitue des donn6es simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" donnee ; cela pourra 6tre realise, par exemple, a l'aide 
de l'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE nom="OTOOBE" 

20 - lecture, a l'aide de la fonction correspondante du SGBDR, de tous les 

ensembles 41 de la table 4 ayant, dans lew donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de l'ensemble 31 venant d'Stre retrouve 
dans la table 3, c'est-a-dire, lecture des deux ensembles 41 1 et 41 2 
constitues respectivement des donnees simples "cle" 11, "rue" 15i, "ville" 

25 16i d'une part, et des donnees simples "cle" 11, "me" 15 2 , "ville" 16 2 

d'autre part ; en supposant que la valeur contenue dans la donnee "cle" 1 1 
de Tensemble 31 retrouve precedemment soit egale a 1234, cela pourra 
8tre obtenu, par exemple, a l'aide de l'instruction SQL : 
SELECT * FROM "EntreeAnnuaire_l " WHERE cle=1234 

30 ~ lecture, a l'aide de la fonction correspondante du SGBDR, de tous les 

ensembles 51 de la table 5 ayant dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cie" 11 de l'ensemble 31 venant d'etre retrouv6 
dans la table 3, c'est-a-dire, lecture des trois ensembles 51 1, 51 2 et 51 3 
constitu6s respectivement des donnees simples "cle" 11 et "contact" 17 L 

35 pour le premier, des donnees simples "cle" 11 et "contact" 17 2 pour le 

second, et "cle" 11 et "contact" 17i pour le troisieme ; en supposant 
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toujours que la valeur contenue dans la donnee 1 "cle" de l'ensemble 31 
retrouve soit egale a 1234, cela pourra etre obtenu, par exemple, a l'aide 
de l'instruction SQL : 

SELECT * FROM "EntreeAiinuaire„2" WHERE cle=1234 
5 De mSme que pour les operations d'ecriture, de lecture ou de suppression, on 

constate que, dans la technique anterieure, on relit au total de six ensembles de 
donnees depuis les tables 3, 4 et 5 pour retrouver l'ensemble des donnees 
correspondant a l'objet 6 recherche. 

En se referant maintenant a la figure 2, dans le pro cede de 1'invention, la 

10 base de donnees 2 comporte une table principale 3 stockant les ensembles 31 de 
donnees simples en nombre fixe "cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, 
et cette table principale est en relation avee une unique table annexe 7 contenant les 
ensembles 71 de donnees simples en nombre variable, constitu^s des donnees 
simples "contact" 17. De fa?on classique, une donnee d'identification unique "cle" 

15 11, presente dans les ensembles 31 et 71 respectivement stockes dans les tables 3 et 
7, est utilisee pour mettre en relation, c'est-a-dire faire se reTerencer, la table 
principale 3 et la table annexe 7, et pour identifier de fa9on unique un objet 6 dans la 
base de donnees 2. 

1 °l Ecriture d'un objet 6 dans la base de donn6es 2 

20 L'ecriture, ou creation, d'un objetidentifte par une valeur unique telle que 

1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
"telecopie" 14, associees aux donnees simples "rue" 15, "yille" 16 et "contact" 17 en 
nombre variable, comportera, dans le procede de 1'invention, les etapes suivantes : 

- ecriture de l'ensemble d'informations principal 31, constitue des donnees 
25 simples "cle" 1 1, "nom" 12, "telephone" 13 et "telecopie" 14, a l'aide de 

la primitive adequate du SGBDR, ce qui conduit a une operation 
d'ecriture pour cet ensemble 31 ; en supposant toujours que la valeur 
pour la donnee "cle" 1 1 soit 1234, cela pourra etre realise" a l'aide d'une 
instruction SQL telle que : 
30 INSERT INTO "EntreeAnnuaire main" (cle, nom, telephone, telecopie) 

VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 

01") 

- stockage de la valeur 1234 dans les donnees "cle" 1 1 des trois ensembles 
de donnees simples 71 1, 712, 7I3, stockage de la premiere donnee "rue" 

35 dans la donnee 15 1 de l'ensemble 71 1 de la table 7, stockage de la 

premiere donnee "ville" dans la donnee \6\ de l'ensemble 71 1, stockage 
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de seconde donnee "rue" dans la donnee 152 de I'ensemble 71 2, stockage 
de la seconde donnee "ville" dans la donnee I62 de I'ensemble 71 % 
stockage de la premiere donnee "contact" dans la donnee 17i de 
I'ensemble 7 1 1, stockage de la seconde donnee "contact" dans ladonn6e 
5 172 de I'ensemble 7l 2 , et stockage de la troisieme donnee "contact" dans 

la donnee 173 de I'ensemble 7I3 ; 
- initialisation de la donnee 20i a la valeur bool^enne VRAI puisque les 
donnees simples "rue" 15i et "ville" I61 correspondantes sont presentes 
dans 1'ensemble 71 i, initialisation de la donnee 21 1 a la valeur VRAI 

10 puisque la donnee "contact" 17j correspondante est presente dans 

I'ensemble 71], initialisation de la donnee 2O2 a la valeur VRAI puisque 
les donnees simples "rue" 152 et "ville" I62 correspondantes sont 
presentes dans 1'ensemble 71 2, et initialisation de la donnee 21 2 a la 
valeur VRAI puisque la donnee "contact" 172 correspondante est 

.15 presente dans I'ensemble 71 2 ; par contre, initialisation de la donnee 20 3 a 

la valeur FAUX puisque les donnees simples "rue" 15 3 et "ville" I63 
correspondantes sont absentes de I'ensemble 7I3 ; enfm, initialisation de 
la donnee 2I3 a la valeur VRAI puisque la donnee "contact" 173 
correspondante est bien presente dans I'ensemble 7I3 ; 

20 - ecriture les trois ensembles 71 2 , 7I3 dans la base de donnees 2 h 

l'aide d'instructions SQLtelles que ; 

INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, 
presence_contact, rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "3bis,rueduDocteur-Foucault", "92000 NANTERRE", 
25 "M. Laurent QUEREL") 

INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, 
presence_contact, rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "34, bd Haussmann", "75009 PARIS", "M. Jean-Francois 
QUENTIN") 

30 et : 

INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, 

presence_contact, rue, ville, contact) VALUES (1234, FALSE, 
TRUE, "", "M. Gilles ANDRE") 
Ainsi, dans le procede selon l'invention, le nombre d'ecritures dans la base 
35 de donnees 2 est egal a quatre, au lieu de six dans la technique anterieure. 
2°/ Relecture d'un objet 6 dans la base de donnees 2 
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La lecture d'un objet 6, ayant pour donnee unique "cle" 11 une valeur 
donnee telle que 1234, et compm-tant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples "me" 15, "ville" 16 et 
"contact" 17 en nombre variable, se fera, dans le procede de l'invention, par les etapes 
5 suivantes : 

- lecture, a l'aide de la fonction correspondante du SGBDR, de l'ensemble 
principal 31, constitue des donnees simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donnee "cle" 11 a la valeur 
donnee 1234, ce qui conduit a une operation de lecture pour cet 

1 0 ensemble ; cette operation de lecture pourra etre realisee, par exemple, a 

l'aide de l'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE cle=1234 

a l'aide des donnees prdsentes dans l'ensemble 31, le proced6 de 

l'invention restitue les donnees fixes de l'objet 6 ; plus pr^cisement, le 

1 5 proc6d6 initialise la donnee en nombre fixe "nom" de l'objet 6 ft l'aide de 

la donnee 12 presente dans l'ensemble 31 relu, il initialise la donnee en 
nombre fixe "telephone" de l'objet 6 a l'aide de la donnee 13 de ce mSme 
ensemble, et il initialise la donnee en nombre fixe "telecopie" de l'objet 6 
a l'aide de la donnee 14 ; 

20 - lecture, dans la table 7, des ensembles 71 de cette table comportant la 

valeur 1234 dans leur donnee "cle" 11 ; cela pourra Stre realise 1 a l'aide 
d'un instruction SQL telle que : 

SELECT * FROM "EntieeAnnuaire_annex" WHERE cle=1234 
les trois ensembles de donnees 71 1, 71 2 , 7I3 sont ainsi relus, moyennant 
25 trois operations de lecture d'ensemble de donnees dans la base de donnees 

2; 

ainsi que cela a 6te decrit pr&edemment, ces trois ensembles 71 j, 71 2 , 
7I3 de donnees sont chacun consumes de la donnee "cle" 11, des donnees 
simples en nombre variable "rue" 15, "ville" 16 et "contact" 17, et des 
30 donnees 20 et 21 indiquant respectivement la presence ou non de 

l'ensemble en nombre variable "rue", "ville" et de la donnee en nombre 
variable "contact" dans l'ensemble 71 conceme ; 

- reconstitution des donnees variables de i'objet 6 a l'aide des donnees 
presentes dans les ensembles de donnees 71 1, 7U, 7I3 preced" eminent 

35 relus ; pour cela, le procetle examine les donnees 20 et 21 dans chaque 

ensemble 71 \, 71 2> 71 3 relu ; 
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plus precisement, si le contenu de la donnee booleenne 20i 
contenue dans l'ensemble 71 1 est VRAI, cela signifie qu'il existait a 
l'origine un premier ensemble "rue", "ville" dans l'objet 6 stocke ; 
dans ce cas, le procecle selon l'invention creera alors un premier 
sous-objet en nombre variable "adresse" dans l'objet 6 ; il remplira 
les donnees en nombre variable "me" et "ville" de ce premier sous- 
objet avec respectivement les donnees 15i et 16; contenues dans 
l'ensemble 71i ; de mSme, si le contenu de la donn6e booleenne 21i 
est vrai, cela signifie qu'il existait a l'origine une premiere donnee 
en nombre variable "contact 11 dans l'objet 6 ; dans ce cas, le procede" 
de l'invention creera une premiere donn6e en nombre variable 
"contact" dans l'objet 6 ; 

en utilisant la meme demarche que ci-dessus, le procdde" de 
l'invention creera un second et un troisieme sous-objet "adresse" en 
nombre variable "rue", "ville" si les contenus des donnees 
booleennes 20 2 et 20 3 contenues respectivement dans les ensembles 
7h et 7I3 sont VRAI, et il initialisera les donnees "rue" et "ville" 
de ces second et troisieme sous-objets en nombre variable "adresse" 
avec les donnees respectivement 152 et I62 d'une part, et 153 et I63 
d'autre part respectivement contenues dans l'ensemble 7I2 et 
l'ensemble 71 3 ; 

de mSme, le proceed de l'invention creera une seconde et une 
troisieme donnee en nombre variable "contact" si les contenus des 
donnees booleennes 2I2 et 2I3 contenues respectivement dans les 
ensembles 712 et 7I3 sont VRAI, et il initialisera ces seconde et 
troisiemes donnees en nombre variable "contact" avec les donnees 
17 2 et 17 3 respectivement contenues dans l'ensemble 71 2 et 
l'ensemble 71 3 ; 

en supposant que les donnees relues proviennent de l'exemple 
d'ecriture d'objet 6 precedemment decrit, les donnees simples 20 1, 
20 2 , 21 1, 2I2 et 2I3 seront a. la valeur VRAI, tandis que la donnee 
2O3 sera a la valeur FAUX ; dans ces conditions, le procede de 
l'invention reconstituera exactement deux ensembles de donnees 
"adresse" en nombre variable dans l'objet 6 relu, ainsi que trois 
donn6es en nombre variable "contact" ; l'objet 6 d'origine sera done 
parfaitement reconstitue. 
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Pour relire l'objet 6, le procedfi effectue done au total trois operations de 
lecture d'ensembles de donnees dans la base de donnees 2, contre six pour la 
technique ant6rieure. 

37 Suppression d'objet 6 dans la base de donnees 2 
5 La suppression d'un objet ayant pour donn6e "cle" 1 1 une valeur donnde, par 

exemple 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples en nombre variable 
"rue" 15, "ville" 16 et "contact" 17, se composeia, dans le procedS de l'invention, des 
stapes suivantes : 

10 - suppression de l'ensemble principal 31, constitue" des donnees simples 

"cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, ayant pour donnee 
"cle" 11 la valeur donnee 1234, a 1'aide de la fonction correspondante du 
SGBDR ; cela pourra etre realist, par exemple, a l'aide de l'instruction 
SQL: 

1 5 DELETE FROM "EntreeAnnuaire„main" WHERE cle=1234 

- suppression de l'ensemble annexe 71, ayant pour donnee "cle" 11 la 
valeur donnee 1234, a l'aide de la fonction correspondante du SGBDR ; 
celapourra Stre realist, par exemple,. a l'aide de l'instmction SQL : 
DELETE FROM "BntreeAnnuaire_annex" WHERE cle=1234 

20 A nouveau, le nombre d'opeiations de suppression d'ensembles de donnees 

par le SGBDR s'eleve a un total de quatre dans le procede" de l'invention, contre six 
dans la technique anterieure. 

47 Recherche d'un objet 6 dans la base de donnees 2 

- recherche, a l'aide de la fonction correspondante du SGBDR, de 
25 l'ensemble principal 31, constitue des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" donnee ; cela pourra etre r(5alis6, par exemple, a l'aide 
de 1'instruction SQL : 

SELECT * FROM "EntieeAnnuairejtnain" WHERE nom="OTOOBE" 
30 - lecture, a l'aide de la fonction correspondante du SGBDR, de tous les 

ensembles 71 de la table 7 ayant, dans leur donn6e "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de l'ensemble 31 venant d'6tre retrouve 
dans la table 3, e'est-a-dire, lecture des trois ensembles 71 1, 71z et 71 3 
ayant la structure de donnees prec^demment decrite ; en supposant que la 
35 valeur contenue dans la donnee "cle" 11 de l'ensemble 31 retrouve' 
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prec£demment soit egale a 1234, cela pourra Stre obtenu, par exemple, a 
l'aide de Instruction SQL : 

SELECT * FROM TnneeAimuairejannex" WHERE cle=1234 
- reconstitution des donnees ou des sous-objets en nombre variable de 
5 l'objet 6 a relire a l'aide des donnees contenues dans les trois sous- 

ensembles relectare ; cette reconstitution est.identique a celle ddcrite au 
paragraphe 2°/ ci-dessus ; en consequence, elle ne sera pas d6crite plus en 
detail. 

A nouveau, le nombre d'operations de recherche d'ensembles de donnees par 
10 le SGBDR s'61eve a un total de quatre dans le proc&le de l'invention, contre six dans 
la technique anterieure. 

Ainsi, dans les quatre operations de base effectuees par un SGBDR, 
l'utilisation du proc6d<§ de l'invention permet une reduction d'un tiers du nombre 
d'op6rations d'ensembles de donnees dans tous les cas. L'exemple pr6sent<S ci-dessus, 
15 volontairement simple pour des raisorts de clart6 de l'expose, ne rend pas 
necessairement bien compte des gains tres importants que peut apporter le proced6 
dans un cas pratique comportant un nombre tables en relation beaucoup plus 
important. 

Dans un cadre plus general, on d6signe, dans ce qui suit, par N a le nombre 
20 de tables annexes Ti, par N p le nombre total d'ensembles principaux 31 dans la table 
principale 3, et par Kj, pour i valiant de 1 a N a , le nombre total d'ensembles de 
donnees presents dans une table annexe Tj. 

Avec ces conventions, dans la technique anterieure, le nombre moyen 
d'operations pour effectuer une entree-sortie concernant un objet 6 dans une table Tj 
25 donnee sera, en moyenne, egal a Kj/N a , et le total general pour une entree-sortie 
complete comprenant l'ensemble principal 31 et les N a ensembles de donnies 
presents dans les N a tables annexes Tj sera done egal a : 

Na 

30 Dans le cas du precede" de la pr<5sente invention, le nombre d'entrees-sorties 

necessaire pour obtenir les ensembles de donnees contenus dans l'unique table 
annexe sera done egal en moyenne a Max du fait que l'unique table annexe 

comporte un nombre d'ensembles egal au maximum des nombres d'ensembles 
presents dans les ensembles d'ensembles en relation ; par consequent, le total general 
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pour une entree-sortie complete comprenant l'ensemble principal 31 et les ensembles 
de donnees contenus dans 1'iinique table annexe sera done 6gal a : 

Na 

Nproc = 1 + Max (Kj)/N p 

5 On voit que sauf circonstance tres exceptionnelle, le nombre moyen 

d'entrees-sorties N pro <; avec le procede de la presente invention sera toujours tres 
inferieur au nombre moyen d'entrees-sorties N an t sans ce proc£de\ Dans le cas 
favorable, mais relativement frequent, ou le nombre d'ensembles de donnees est 
sensiblement le m&ne dans les diverses tables annexes, le proced6 selon l'invention 
1 0 permet un gain en performances atteignant un facteur egal au rapport N proc /N an t, e'est- 
a-dire : 

Na 

1+ Max(Ki)/N P 

M 



1+ Z Kj/Np 

i-1 



soit en utilisant l'hypothese que les divers K\ sont sensiblement 6gaux entre eux, el, 
1 5 done au maximum d'entre eux : 

Na 

l + Max(Ki)/N„ 



Nn 

l + NaxMax(Ki)/N P 

i=l 



Na 

soit en negligeant 1 devant Max (Ki)/N p , un rapport de valeur 1/N a , ce constitite une 
diminution tres importante du nombre d'entrees-sorties des que le nombre de tables 
annexes augmente. 

20 Ce procede est done particulierement souhaitable dans toutes les 

applications de bases de donnees relationnelles dans lesquelles les performances 
constituent un facteur critique, telles que les applications temps reel ou celles 
utilisant des serveurs de bases de donnees tres sollicites, comme ceux qui se 
rencontrent dans les reservations centralisees par un reseau, ou dans la consultation 

25 de bases de donnees via le reseau mondial Internet. 

En outre, l'utilisation du langage XML pour representer les objets stockes 
dans la base de donn6es 2 permet l'utilisation de patrons d'objets XML pour filtrer 
certaines donnees des objets 6 entrants et sortants de la base de donnees 2. Ainsi, 
dans le mode de realisation pref6r6 de la presente invention, des patrons d'objets 
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XML 61, collectivement denornmes I/O Format et conformes a une description XML 
Schema, sont utilis6s pour realiser un tel filtrage. 

Plus precis6ment, ces patrons d'objets XML I/O Format 61 supprimeront 
cerlaines donnees sensibles des objets entrants, comme des donnees concemant la 
5 validite des donnees contenues dans un objet 6, de facon a ce que ces donnees 
sensibles ne puissent etre, en tout etat de cause, modifiees depuis le reseau 60, et a ce 
que leur modification ne puisse etre effectuee que pai' un operateur intervenant 
directement sur l'ordinateur serveur 1. 

De meme, les patrons d'objets XML I/O Format 61, en fonction des donnees 

10 effectivement utilisees par un utilisateur sur le r6seau 60, supprimeront dans les 
donnees d'un objet 6 transmises sur le reseau 60 les donnees qui ne seraient pas 
utilisfes par ledit utilisateur. Compte-tenu de ce que, dans la pratique, les donnees 
transmises pour un objet 6 ne repr6sentent habituellement qu'une faible partie de 
l'ensemble des donnees de cet objet, ce precede" permet une reduction substantielle du 

1 5 volume des donnees transmises pai- l'ordinateur serveur 1 , ce qui est particulierement 
interessant dans le cas d'ordinateur serveur 1 tres charge, tels que ceux qui se 
rencontrent dans l'Internet. 

En outre, ce procede" permet de prendre en compte differents niveaux de 
securite attaches aux utilisateurs se connectant via le reseau 60, en associant a chaque 

20 niveau de securite un patron eliminant des donnees transmises a l'utilisateur les 
donnees non autorisees pour le niveau de securite de l'utilisateur. 

En outre, du fait que ce proced6 garantit que seules les donnees conformes 
au patron d'objet I/O Format 61 utilise seront transmises, il n'y aura pas lieu de 
deraander la restitution par la base de donnees 2, des donnees elimin6es par le patron 

25 d'objet I/O Format 61 utilise, et ainsi les donnees apparaissant dans les requStes SQL 
"SELECT" effectives par le moteur COS Engine pourront 6tre limitees aux seules 
donnees transmises, ce qui diminuera de facon toute aussi sensible la charge 
d'entr6es-sorties dans la base de donnees 2 dans 1'ordinateur serveur 1 . 

Ce proceed permet de focaliser la requete sur les tables de la base de 

30 donnees 2 et les donnees dans ces tables 3 et 7 qui sont effectivement utilises dans 
la requSte d'un utilisateur. Ainsi, dans le cas ou aucune donnee de la table annexe 7 
n'est utilisee dans la requete, le proc6d6 n'accedera pas a cette table 7 pour la requete, 
ce qui, a nouveau, permettra d'ameliorer sensiblement les performances de 
l'ordinateur serveur 1 mettant en osuvre le precede de l'invention. 

35 Ainsi, l'utilisation du format XML et d'un patron d'objet au format XML 

permet d'imposer des regies de securite sur les donnees entrantes, de limiter 
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l'utilisation de la base passante du reseau 60 aux seules donnees necessaires et de 
diminuer en due proportion le volume des donnees echangees avec la base de 
donnees 2. 

Dans le mode de realisation decrit ci-dessus, la donnee "cle" 11, identifiant 
5 de facon unique un objet 6, a &e indiquee, pour des raisons de simplicity de l'expose, 
comme etant ger6e de facon explicite par le proc6de de l'invention. Toutefois, cette 
technique explicite n'est en auciuie maniere obligatoire, et elle peut parfaitement etre 
remplacee par toute autre technique equivalente pouvant etre offerte pai' le SGBDR 
utilise. 

10 De meme, cette donnee "cle" 11 a ete" decrite comme 6tant constituee d'un 

seul nombre entier, mais elle peut tout aussi bien Stre constituee de plusieurs parties. 
Par exemple, dans le mode de realisation prefere" de l'invention, une donnee "cle" 1 1 
unique, appelee Object IDentifier ou OID, est obtenue pour chaque objet 6 en 
concatenant une premiere partie constituee du nom logique du serveur 1 sur lequel 

15 reside la base de donnee 2, une seconde partie constituee du numero de la table 
principale 3 dans la base de donnee 2, et une troisieme partie constituee du numero 
d'enrcgistrement de l'ensemble dc donnees principal 3 1 dans ladite table 3 . 

Le nom logique du serveur 1 etant unique sur le reseau 60, la base de 
donnees 2 £tant unique sur le serveur 1 ou elle est stock6e, le numero de la table 3 

20 etant unique dans la base de donnees et le numero d'enregistrement de l'ensemble de 
donnees principal 3 1 etant unique dans la table 3, l'OID 1 1 ainsi obtenu pour un objet 
6 sera done unique parmi l'ensemble des OID identifiant les objets 6 accessibles via 
le reseau 60. En outre, ce type de donnee "cle" 1 1 pr6sentera l'interet de permettre de 
localiser precisement le lieu de stockage d'un objet 6 quelconque sur la seule base de 

25 son OID 11 assocte. 

Par ailleurs, dans l'exemple decrit ci-dessus, il a et6 fait reference a une 
application de type annuaire, mais le precede de l'invention est egalement utilise dans 
des application de type conferences ou publications. 

D'une facon generate, la description ci-dessus ne doit pas Stre comprise 

30 comme r&iuisant en quoi que ce soit la portee de la presente invention telle que 
revendiquee dans les revendications annexees. 
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REVENDICATIONS 

1 , Procede de stockage d'objets informationnels ou objets (6), dans une base de 
donnees relationnelle (2) stockee dans un ordinateur serveur (1), ladite base 
de donnees relationnelle (2) etant constitute de tables, chaque table etant 

5 constituee d'un tableau d'ensembles de donnees simples, lesdits ensembles 

ayant la m6me structure de donnees dans une m6me table, chaque donnee 
simple d'une table etant designee par un identifiant unique dans ladite table, 
un objet (6) etant constitue d'une ou plusieurs donnees simples pouvant etre 
stockees dans une table de ladite base de donnees (2), et/ou d'un ou plusieurs 

10 objets emboites dans ledit objet, ledit emboitement pouvant etre realise sur 

un nombre quelconque de niveaux pour realiser un objet (6), un objet 
embofte' ou une donnee simple etant dit localement en nombre fixe s'il ou 
elle apparait exactement une fois dans l'objet le ou la contenant 
immediatement et etant dit localement en nombre variable dans le cas 

15 contraire, une donnee simple appaiaissant a un niveau quelconque dudit 

objet (6) etant dite globalement en nombre fixe si elle est localement en 
nombre fixe et si tous les objets la contenant sont localement en nombre 
fixe, une donnee simple appaiaissant a un niveau quelconque dudit objet (6) 
etant dite globalement en nombre variable si elle est localement en nombre 

20 variable ou si l'un quelconque des objets la contenant est localement en 

nombre variable, lesdites donnees globalement en nombre fixe d'un objet a 
stacker (6) etant stockees dans un ensemble de donnees principal (31) stocke 
dans une table principale (3) de ladite base de donnees (2), lesdites donnees 
simples globalement en nombre variable dudit objet a stacker (6) etant 

25 stockees dans une ou une ou plusieurs tables annexes (4, 5, 7) de ladite base 

de donnees (2), caracterise par le fait que, lorsqu'elles existent, les donnees 
simples globalement en nombre variable desdits objets (6) sont stockees 
dans une unique table annexe (7) de ladite base de donnees, le procede" 
creant un ou plusieurs ensembles de donnees annexes (71) pour stacker 

30 lesdites donnees simples globalement en nombre variable dans ladite unique 

table annexe (7). 

2. Proceed selon la revendication 1, dans lequel chacun desdits un ou plusieurs 
ensembles annexes (71) eventuelleraent stockes dans ladite unique table 
annexe (7) comporte en outre un ensemble (72) d'indicatems booleens, 

35 chaque indicateur booleen etant associe a une donnee particuliere desdites 

domiees simples globalement en nombre variable stockees dans ledit 
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ensemble annexe (71), ledit indicateur booleen indiquant si ladite donnee 
simple globalement en nombre variable associee est defmie ou non dans 
ledit ensemble annexe (71). 

3. Precede selon la revendication 2, dans lequel certains desdits indicateurs 
5 bool6ens dudit ensemble (72) d'indicateurs bool6ens sont communs a 

plusieurs donnees simples globalement en nombre variable lorsque lesdites 
donnees simples sont localement en nombre fixe dans un meme objet les 
contenant immediatement. 

4. Procede selon l'une quelconque des revendications precedentes, dans lequel 
1 0 ledit ensemble principal (31) associe au dit objet (6) k stocker comporte une 

donate (1 1) permettant d'identifier de facon unique ledit ensemble principal 
(31) dans ladite table principale (3). 

5. Precede" selon la revendication 4, dans lequel ladite donnee unique (11) est 
unique dans ledit ordinateur serveur (1), 

15 6. Precede selon l'une des revendications 4 ou 5, dans lequel ladite donnee 
unique (11) stockee dans ledit ensemble principal (31) associe au dit objet 
(6) a stocker est en outre stockee dans chacun des ensembles annexes (71) 
associes au dit objet (6) a. stocker, pour permettre la mise en relation dudit 
ensemble principal (3) et du ou desdits ensembles annexes (71) eventuels 

20 associes au dit objet (6) a stocker. 

7, Precede selon l'une quelconque des revendications 4 a 6, dans lequel ladite 
donnee unique (1 1) est constitu6e du nom logique de l'ordinateur serveur (1) 
sur ledit reseau (60), du numero de table de ladite table principale (3) dans 
ladite base de donnees (2) et du numero d'ensemble de donnees dudit 

25 ensemble principal (3 1 ) dans ladite fable principale (3), ledit nom logique de 

1'ordinateur serveur (1) etant unique sur ledit reseau (60), ladite base de 
donnees (2) &ant unique sur ledit ordinateur serveur (1), ledit numero de 
table de ladite table principale (3) etant unique dans ladite base de donnees 
(2) et ledit num&o d'ensemble de donnees dudit ensemble principal (31) 

3 0 etant unique dans ladite table principale (3) . ; 

8. Proc£d6 selon l'une quelconque des revendications precedentes, dans lequel 
deux objets (6) a stocker sont dits de meme type s'ils sont constitu6s de 
donnees simples et d'objet emboites de meme type, deux objets (6) de mSme 
type ayant en commun un mSme identifiant et les donnees simples et/ou les 

35 objets emboites se correspondant a. un niveau quelconque desdits objets (6) 



) 



WO 02/03245 PCT/FR00/01902 

36 

de m&ne type ayant en commun mi ineme identifiant, unique dans Pobjet les 
contenant imm^diatement. 

9. Precede selon la revendication 8, dans lequel le proc6d6 cree un identifiant 
global pour tous les objets (6) de meme type et pour toutes les donnees 

5 simples se correspondant a un niveau quelconque desdits objets (6) de 

meme type, ledit identifiant global etant ledit identifiant commun pour 
lesdits objets de m6me type, et ledit identifiant global 6tant obtenu, pour 
chacune desdites donnees simples se correspondant, par la concatenation des 
identiflants, dans les objets les contenant immSdiatement, de tous les objets 
1 0 contenant ladite dorrnee simple, et de l'identifiant de ladite donnee simple 

dans l'objet la contenant irnmediatement 

10. Proc^de selon la revendication 9, dans lequel le nombre de caracteres de 
l'identifiant global est tronque au nombre de caracteres permis par ladite- 
base de donnees (2) pour l'identifiant d'une donnee stockee dans une table de 

1 5 ladite base de donnees (2). 

11. Procede selon la revendication 10, dans lequel une ambigu'fte pouvant 
apparaitre du fait de ladite troncature est resolue en effectuant les etapes 
consistant a : 

- remplacer le dernier caractere alphabetique de l'identifiant global par le 
20 chiffre zero, ainsi que les eventuels chiffres le suivant ; 

- augmenter d'une unite le nombre constitu6 par l'ensemble des chiffres 
apparaissant a la fin dudit identifiant global jusqu'a ce que l'ambigui'te 
disparaisse ou que les chiffres a la fin dudit identifiant global soient 
entierement constitues de chiffres neuf ; 

25 - repeter les etapes precedencies depuis le d6but lorsque les chiffres 

apparaissant a la fin dudit identifiant global sont entierement constitues 
de chiffres neuf a Tissue de l'Stape piecedente. 

12. Precede* selon 1'un quelconques des revendications prec^dentes, dans lequel 
les objets (6) stockes dans la base de donnees (2) sont re9us ou transmis par 

3 0 l'ordinateur serveur ( 1 ) via un reseau infomaatique (60) de type Internet. 

13. Procede selon Tune des quelconques des revendications prec6dentes, dans 
lequel les donnees simples constituant lesdits objets (6) stockes dans ladite 
base de donnees (2) sont de type texte. 

14. Proc6de selon la revendication 13, dans lequel lesdites donnees simples de 
3 5 type texte sont des donnees ecrites en langage XML. 
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15. Procede selon la revendication 14, dans lequel lesdites donnees ecrites en 
langage XML sont conformes aune description (92) de type XML Schema. 

16. Procede selon la revendication 15, dans lequel un ensemble de donnees (95) 
au format XML est obtenu par une traduction automatique de ladite 

5 description (92), ledit ensemble de donnees (95) et un ensemble de donnees 

compl&nentaire (96) &ant a leur tour traduits automatiquement en langage 
SQL pour defmir et gerer la structure de la base de donnees (2), et pour 
contr61er les echanges de donnees avec ladite base de donnees (2). 

17. Procede selon Tune quelconque des revendications 14 a 16, dans lequel une 
1 0 partie des donnees simples des objets (6) recus par ledit reseau (60) de type 

Internet est supprimee a l'aide dhin patron, ou modele, d'objet (61) ecrit en 
langage XML, pour Interdire la modification desdites donnees simples via 
ledit reseau (60). 

18. Procede' selon l'une quelconque des revendications 14 a 17, dans lequel une 
1 5 partie des donnees simples des objets transmis via ledit reseau est supprimee 

a l'aide d'un patron d'objet (61) ecrit en langage XML pour limiter la 
transmission sur ledit reseau (60) a certaines donnees simples desdits objets 
(6). 

19. Procede selon la revendication 18, dans lequel la suppression de d'une partie 
20 des donnees simples contenues dans les objets (6) permet en outre 

d'optimiser les requStes a ladite base de donnees (2). 

20. Systeme de stockage d'objets irrformationiiels ou objets (6), dans une base 
de donnees relationnelle (2) stockee par un ordinateur serveur (1), 
caracterise par le fait qu'il met en ceuvre le procede" selon l'une quelconques 

25 des revendications precSdentes. 
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